Since the "t" of tar means tape, a tar program which supports SCSI devices should support tape units: however, that part of suntar is somewhat immature and probably only it version 2.0.4 it should be considered no more "beta" software, mainly because
1) tape units can't be found everywhere, and sometimes there are problems with cabling (e.g. Sun units do not use the standard SCSI 50-pin connectors). Hence we've personally tested suntar 2.0 on only three tape units, and only one of these tests lasted enough to try all the solutions and not only identify the problems.
2) the SCSI standard is not perfectly clear, and even where the standard is clear and does not specifies that details are "vendor specific", some vendors do not follow it faithfully, so the situation is somewhat chaotic
3) the SCSI committee defined a standard set of commands which should allow one to control devices from different manufacturers without writing specific code (i.e. device driver) for each one: however, this feature has had a very low priority: most commands and features are optional, and there is no way to know which ones are supported and which ones are not: for a while almost all manufacturers included a list of supported commands (but not of supported options) in the "vendor specific" informations returned by the SCSI "inquiry" command, but older devices didn't do that, and unfortunately SCSI-2 did not make that list official, hence manufacturers are now deleting that information in new versions of SCSI controllers that once had them.
Suntar 2.0.2 was tested on a Exabyte EXB-8200 unit, and suntar 2.0.0beta4 on a ARCHIVE VIPER (a quarter-inch unit). Tests were usually successful. Early versions caused a lot of failure reports, but now it seems that suntar handles tapes rather well: in the last year and an half reported problems were minor.
Anyway, if suntar fails you might try the other freeware tar program for the Macintosh, Craig Ruff's tar, which in version 4.0 added support for tapes. And a user of suntar wrote us that there is a commercial tar for the Macintosh, here is what he could know about it:
it's part of "QuTape" (695 $)
Novastor Corp.
30961 Agoura Road, Suite 109
Westlake Village, CA 91361
Phone: +1 (818) 707-9900
Guide to configuration for tapes
Sorry, suntar can't always self-configure for your tape unit. The SCSI standard is rather poor in this regard, and we have not the know-how to build a table of configurations for all kinds of units. Often, the default settings are OK, but it this does not work, you must configure it, and unfortunately this means understanding some very technical matters. Obviously, you may prefer to try all the configurations, without trying to understand what each means, but since most options are independent you can't really try all the combinations, they are too many…
The first thing to learn is that the tape options for suntar are under "Rarely used options", available only if "Expert mode" is checked. Some options were collected together under two names, "supported operations" and "unsupported operations", which must contain a list of numbers separated by commas: if an operation is in neither list, then suntar uses the default value (that's why there are two lists). E.g. the correct configuration for the Exabyte is:
unsupported: 2,3,11 (but maybe it was a problem of timeouts, I did not try
again after correcting that)
supported: 0,1,7,9,10,13 (since it's the default none is required; you may
add 4 if you want)
MODE SELECT on open: yes
This is the configuration for an Archive Scorpion 60 Mbyte unit:
unsupported: 1 (maybe also 3: the beta-tester did not try that)
supported: 0,2,7,10,11,13
block strategy=don't care (it's a fixed blocks unit)
do MODE SELECT=don't care (it's a fixed blocks unit)
and finally for a un SONY SDT-1000:
strategy: software fixed
blocking factor: 20
unsupported 1,3
supported 0,2,5,7,9,10,11,13,14
MODE SELECT on open: yes
And we were told that an Archive Python worked well with the default settings.
A tape is a rather flexible device, since in most cases it allows data to be written in "blocks" of any size. On a UNIX machine this feature is hidden by the device driver (in UNIX all devices are a simple stream of bytes) but running on the Mac suntar must know about blocks and block sizes. If the block size known to the application is wrong the tape unit may refuse to return any byte, or at least issue an error. Furthermore, the old SCSI manager in the Mac ROM was written with hard disks in mind, and it may report an error to the application even when the tape unit correctly fulfilled the request (SCSI manager 4.3 has removed that limitation).
So, in order to use suntar with a "variable-size blocks" tape unit you must configure the way it uses to handle block sizes: these methods are 4, and you may be obliged to try 3 of them looking for the correct one.
a) fixed blocks
It's automatically selected for a "fixed block" tape unit, that is when minimum block size=maximum block size, regardless of the value of "tape block strategy". So, if the minimum and maximum size are identical (e.g. 512 bytes for the VIPER) you need not read the rest of the discussion about block sizes.
The following options may modify the behaviour in this mode:
supported/unsupported bit 4: if it's supported, suntar makes a single request for a number of adjacent blocks, that's faster but in some cases suntar might fail to count correctly the bytes in the last transfer and hence incorrectly identify the position of the end-of-archive (default: unsupported).
b) really variable blocks
It's obtained by setting "tape block strategy" to any string starting with 'v' or 'y' (e.g. variable).
When reading, suntar tries to fill the buffer, accepting any block length the tape unit has available, with the only condition that it's an integer multiple of 512 bytes.
When writing, it's identical to software fixed blocks.
Unfortunately, there are a number of potential problems and this method, conceptually the simplest for handling variable blocks, might fail to work. On my LC it has always worked, but it exploits an undocumented feature of the Mac ROM which I was told is not supported on the Quadras. The Quadras and PowerMacs support a totally new SCSI Manager (4.3) which has a documented feature which solves the problem, but I've not experimented very much with it.
In this mode the following options are meaningful:
do a MODE SELECT: when opening the device do a MODE SELECT with a block size of 0 (the conventional value meaning "variable sized blocks"). Some units (e.g. Exabyte) don't work in variable mode without this.
supported/unsupported bit 5: if unsupported, do a MODE SENSE before every READ and ask that many bytes (it's an unusual way to do things, but I've written the instructions to do that and it does not harm to let the option there)
c) "software" fixed blocks (the name is not standard, don't expect to see it elsewhere)
It's obtained by setting "tape block strategy" to any string starting with 's' (really, anything not starting with 'v', 'y' or 'f')
When reading, suntar uses the "variable blocks" variant of the SCSI READ command, but expects each block to be 512*"blocking factor" bytes, it's an error to see different block sizes. That's a reasonable strategy since most programs (including all versions of tar) always write blocks of fixed size even when the tape unit is potentially variable-blocks.
When writing, suntar always creates blocks of size 512*"blocking factor".
The blocking factor is another "rarely used option": in theory it should be equal to the -b option passed to tar under UNIX (or 20 if the -b option is not used) but in some cases
the UNIX device driver might ignore that and use its own value. If the value is incorrect, suntar should print the correct value, so you should assign it, close the device (some options are activated only at the next "Open device"), reopen it, rewind and retry.
Options:
do a MODE SELECT: when opening the device do a MODE SELECT with a block size of 0 (on the Exabyte it's required, otherwise it does not work in this mode)
supported/unsupported bit 5: when opening the device do a MODE SENSE and if the returned value is not 0 use that value instead of 512*"blocking factor".
d) "firmware" fixed blocks (the name is not standard, don't expect to find it elsewhere)
It's obtained by setting "tape block strategy" to any string starting with 'f'. This mode exploits a feature of the SCSI command set for tape units, so the "variable blocks" units may accept "fixed blocks" requests.
Options:
do a MODE SELECT: when opening the device do a MODE SELECT with a block size of 512*"blocking factor", in order to oblige the tape unit to work in the fixed-blocks mode
supported/unsupported bit 5: if unsupported, the block size is obtained by a MODE SENSE rather than being 512*"blocking factor", but if its response is 0 then software fixed blocks are used. Obiously, using both this option and the previous one is not very meaningful (the MODE SELECT uses the value from the MODE SENSE, so nothing changes)
supported/unsupported bit 4: see its description for fixed blocks
Some units work in several modes: the Exabyte when reset is in "firmware fixed" mode with a blocking factor of 2, but it may work in "really variable" (do a MODE SELECT=yes), "software fixed" (again do A MODE SELECT=yes, and pay attention to the blocking factor also when reading, not only when writing) and "firmware fixed" (do a MODE SELECT either no or yes if the blocking factor is 2, otherwise yes).
Some suggestions:
Many commands are not performed when the tape is moving or is not in the correct position. So, before launching a tar extraction observe the unit (the Exabyte has a green LED) or use the "see if unit is ready" command in the device menu. Sometimes the Exabyte goes crazy when it receives commands in the wrong moment, and sometimes it's still crazy when powered down and up after that. Similarly, you may use "Error/status info" to be sure that the tape is at beginning of medium, and rewind if it isn't.
When reset, any SCSI unit is in a "UNIT ATTENTION" status, and may refuse to accept commands until it exits from it. In theory this should be accomplished by sending it any SCSI command (e.g. a REQUEST SENSE, performed by "Error/status info") but the Exabyte seemed to pretend something more, e.g. a MODE SENSE, sometimes even two or three MODE SENSEs. The commands performed by suntar at "Open Device" always worked, but after an explicit "Reset" sometimes I had some difficulties to return to a normal status (NO SENSE, or NOT READY if the tape is missing). And, obviously, after an explicit reset the effect of the "do a MODE SELECT" option is lost: if your configuration requires "do a MODE SELECT"=yes, then after a Reset the tape will not work until the correct MODE SELECT is performed (either by closing/reopening or by the "MODE SELECT" command, which appears in the Device menu when verbosity is not 0 (see later).
Since the UNIX tar allows one to place more archives on a single tape, rewinding the tape in order to "go to sector 0" might really place the tape far from your data. Hence suntar avoids to automatically rewind the tape, and you must often use the explicit rewind command in the Device menu. "Skip filemark" commands are good for multiarchive tapes.
Unlike UNIX, the Macintosh was not thought to perform several operations in parallel. So, it does not support the way SCSI uses to allow the computer work while the device performs a slow operation, with one exception (rewind) for which the SCSI committee introduced an alternate method. Slow operations block the Mac, and for a Skip filemark this may last for several minutes, for a "Full erase" even for an hour. Suntar has a timeout, if after that time the operation has not finished it aborts the operation by resetting the SCSI bus. So, you must assign the timeout (rarely used options) before performing a full erase. There is one solution, the new SCSI manager 4.3 supports parallel execution of SCSI commands, but exploiting it is not easy and by now we have not tried.
Suntar was born for floppy disks and its default buffer size (9k) is good for floppy disks but is small for tapes. In order to increase it, simply allocate more memory to suntar. Or, if you don't like to have a different size each time you launch suntar, assign the "buffer size-encoded data" option to something bigger than 18. That's important because the buffer size greatly influences speed: if the buffer is too small, or too big, the tape unit will stop often and wait, so becoming very slow. In theory, SCSI Manager 4.3 and the Thread manager, both introduced with System 7.5, should allow a Macintosh to handle tapes as fast as a UNIX workstation does, that is at the natural speed of the tape, but we had not tried that yet.
If everything seems to fail, suntar offers some opportunities to experiment. When you do option-open device and assign a "verbosity level" greater than 0, suntar allows you to perform a MODE SELECT with any block size (as usual, 0 means "use variable sizes") and/or perform READ commands either fixed (place a "f" before the number) or variable ("v"). That's faster than modifying the blocking factor, closing the device and reopening. N.B. the option key may be pressed before clicking the mouse to select "Open device", or while releasing the button, or while double-clicking in the scrolling list.
A possible series of tests:
Use "MODE SELECT" to set block size to 0 ("MODE SENSE" tells you the current value, it's always wise to check that the command was correctly executed)
Do a "TEST SCSI read" of vnnnn bytes (where nnnn is "blocking factor" times 512): you're emulating "software fixed" mode
Do a "TEST SCSI read" of v1000000 bytes (or any number bigger than above): you're emulating "really variable" mode with a buffer size of 1000000
Now, perform a "mode select" of "blocking factor" times 512 bytes
Do a "TEST SCSI read" of fnnnn bytes (where nnnn is "blocking factor" times 512): you're emulating "firmware fixed" mode
If you want, you may also try other combinations. Anyway, at least one of these three reads should complete without error: on the Mac LC with the Exabyte all three operations succeeded. Be aware that sometimes the unit may go into an "error state" so that before doing an attempt it's better to verify that "Status/error info" tells that the unit is OK. Otherwise, reset it and wait until it's ready and not in error, then do the MODE SELECT and TEST SCSI read.
Remember that a fixed READ issued when the unit is in variable mode or vice-versa should yield a "ILLEGAL REQUEST" error code.
The coding of the "supported tape operation" is:
0 skip file forward
1 skip file backwards (both may be tested from the Device
menu, but beware: the SCSI-1 standard specifies a single error code
for these causes: command not supported, wrong parameters to the
command, the current status of the unit is not compatible with
executing the command (e.g. missing tape, or tape at end of medium):
so a failure does not mean that the command is not supported, unless
the unit supports the new SCSI-2 error codes (additional sense key).
If the "inquiry" data contains the list of supported commands, note that
0,1,2,3 are all implemented by command 11 of group 0, but it need not
implement all four operations
2 skip block forward ("fast forward" movement, may be tested with a
List of an archive containing files longer than the block size)
3 skip block backwards (may be tested by an "Append" command)
4 may use multiple fixed blocks reads and writes (see above)
5 do a MODE SENSE to get block size (see above)
7 write filemark (command 10 of group 0, may be tested from the Device menu)
9 short erase
10 long erase
11 end of medium
13 immediate rewind, that is letting the computer free while the tape unit performs the command
14 in "Drive list", suntar may try to detect the units which exploited the SCSI feature allowing one to connect more devices to a single controller and hence a single ID. Some old drives behave strangely when they're asked about this, so only a 14 in the "supported ops list" enables this.
some SCSI jargon:
MODE SENSE: ask informations about the unit and in particular the block size. But there are a lot of informations, suntar does not try to get all of them (try the freeware SCSI Spy on your hard disk, you'll be surprised…)
MODE SELECT: assign informations about the unit and in particular the block size
REQUEST SENSE: ask more informations about the last error occurred. Since the error code returned by the command which failed is very concise, in practice any program handling SCSI devices must perform a REQUEST SENSE every time a command fails.
bus reset: reset ALL the devices on the SCSI bus. Device manufacturers are usually free to choose what to do at reset, but at least they restore all temporary settings to their initial values. This may mean that the device and its device driver are now configured differently, and that device appears not to work until the driver is reloaded (i.e. the Mac is restarted): it's rare, but happened with old versions of the CD-ROM driver from Apple. When reset, a SCSI printer will abort any print job and maybe print its self-test page. So, a SCSI bus reset is sometimes not desirable, but a lot of units can oblige suntar to do that. Don't ask me why, but a lot of SCSI units when receiving an unknown command lock the bus, failing to release it. They don't say "pardon ? I did not understand", they do nothing, absolutely nothing, not even the simple action of releasing the bus. Now, the SCSI bus is occupied and nothing may be done on it, hence your hard disk(s) can't be accessed. So, suntar tries to reset the device which caused the problem. But the "reset device" command (well, technically it should be called "message": a message may interrupt the execution of a command) is often ignored too. Then, the only way to return to a good status is to reset the bus, hence ALL the SCSI devices connected to your Mac, with all its potential problems. Most hard disks may be reset without any problem, however.
Obviously, I'm waiting to hear news from you: if suntar works with a tape unit, tell me (by E-mail to the address in the readme file or in the about box of the application) which unit it is and how you've configured suntar, or which particular problems it creates and how you solved them. Users of future versions will find these informations in this file, near the informations for the Exabyte, Scorpion and SONY SDT, and they won't be obliged to discover them by themselves. The informations will be much more useful if they're complete, i.e. you tried all the commands associated to a supported/unsupported bit and tried all the block strategies which are meaningful for that unit, but any information is useful. I'd like something like this (the informations from the "inquiry" are printed with verbosity 1):
Device type: Tape unit
Device type qualifier: 0
Removable: yes
ANSI version: 1
VendorID: EXABYTE
ProductID: EXB-8200
Revision: 425A
The list of supported commands is not available
MODE SENSE test
medium type 133
write protected: no
density code 0 blocks 2294048 block size 1024
READ BLOCK LIMITS test
reserved byte=0
minimum block size=1 maximum=245760
-------
unsupported ops: 2,3,11
supported: 0,1,4,7,9,10,13
block strategies and related options:
...... (place here all what you find useful, at least if the unit is "variable length", complete informations would include a description of the results of tests in all the three strategies, and with and without the options)
If, on the other hand, you have problems and can't solve them, well, our problem is that a SCSI operation yields a lot of different error codes, and in order to avoid to overwhelm you with a lot of meaningless numbers, what suntar usually prints is a "summary" error code, chosen among error codes created by Apple, which were not thought for tape units. "Error/status info" is more detailed, but often that's not enough. So, suntar 2 has a "debug mode" which prints all informations about what it's doing (or trying to do) and about error messages from the SCSI device: it's activated by option-open device and assigning a "verbosity level": you won't understand all those data (unless you are a SCSI expert) but maybe those informations will allow us to fix the problem. It's very convenient to use this with a "log file" opened from the "Special" menu.
